This invention relates to a fault-resilient method and apparatus for generating complete correlated IP Multimedia Subsystem (IMS) charging data records upon charging collection function failover.
While the invention is particularly directed to the art of telecommunications, and will be thus described with specific reference thereto, it will be appreciated that the invention may have usefulness in other fields and applications.
By way of background, a type of communication network gaining popularity is an IP Multimedia Subsystem (IMS) network. As set forth in the 3rd Generation Partnership Project (3GPP), IMS provides a common core network having a network architecture that allows for various types of access networks. The access network between a communication device and the IMS network may be a cellular network (e.g., CDMA or GSM), a WLAN (e.g., WiFi or WiMAX), an Ethernet network, or another type of wireless or wireline access network. The IMS architecture is defined by the 3GPP to provide multimedia services to communication devices over an Internet Protocol (IP) network, as IP networks have become the most cost savings bearer network to transmit video, voice, and data. Service providers are accepting this architecture in next generation network evolution.
In IMS networks, the Charging Collection Function (CCF) acts as a charging system, providing for the offline charging for calls and sessions. This offline charging is based on accounting requests sent by the various Network Elements (NEs), implementing the Charging Trigger Function (CTF). The NEs provide accounting requests to the CCF when a configured charging trigger occurs on the NE. The CCF gets these accounting requests via the Diameter Accounting Request (ACR) messages. The ACR messages are acknowledged by an Accounting Answer (ACA) message, which is sent from the CCF to the NE/CTF. Upon receipt of the ACA message, the NE/CTF removes the ACR message from its queue of message to be delivered to the CCF and proceeds to send the next message in the queue to the CCF.
IETF RFC 3588, Diameter Base Protocol, defines a failover strategy whereby a Diameter Client (in this case, NE/CTF) may time out waiting for the acknowledgment (ACA). When the client establishes that the Accounting Server (CCF) is not responding for any reason, the client can failover to a Diameter peer, which is another CCF node for accounting purposes. This results in accounting requests from one call or session to be split across two (or more) CCFs. The complete set of ACRs for the session is not available on any single CCF. This behavior is explained and supported in the standard specifications; see, for example, 3GPP TS 32.298-810, under section 5.1.3.1.16, Incomplete CDR Indication.
However, as a result of this split, each CCF provides an aggregated and correlated Charging Data Record (CDR) for the same session, covering different parts of the session. This means multiple CDRs show up at the billing system, each coming from a CCF that handled part of the session while it was in-service and handling the session accounting requests from the NEs. Also, in case the failover resulted from a complete failure of a CCF, the records held at the failed CCF (or CCFs) are not available until later. While the CCF outage and the resulting delay in providing the CDR to the billing system can be explained, many of the billing mediation systems are not capable of collapsing two or more CDRs that pertain to the same session into one CDR for use by the billing system. Customers using such mediation systems may refuse to accept the Incomplete CDRs. This causes revenue leakage. Additionally, sending two or more CDRs for the same session, especially if there is delay between sending these CDRs to the billing system, potentially results in subscriber queries to the CSR, since these may be perceived as double (or triple) billing for the same session or call. Finally, this mode of handling CCF failures results in generating extra traffic on the link to the billing mediation system, which is counterproductive, since the billing mediation would end up rejecting the Incomplete CDRs eventually.
Therefore, a need exists to handle the failover in such a way that each session or call produces a complete correlated CDR.